ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group01a.txt/000012_icon-group-sender _Wed May 17 07:44:01 2000.msg

Internet Message Format | 2002-01-03 | 4KB

Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00845
    for icon-group-addresses; Wed, 17 May 2000 07:43:27 -0700 (MST)
Message-Id: <[e-mail]>
From: "Ian Trudel" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 17 May 2000 13:52:48 GMT
X-Complaints-To: [e-mail]
X-Trace: carnaval.risq.qc.ca 958571568 24.226.208.172 (Wed, 17 May 2000 09:52:48 EDT)
To: [e-mail]
Errors-To: [e-mail]
Status: RO
Content-Length: 2899

1/ I ain't no C++ support, fellow, fan, or not even like the language. Let's
not talk about it. ::)
2/ The point of my original post is not really Icon reimplementation, but
adding a new feature to the language.
3/ I feel your post "hide" something, like transforming Icon to some OOP
language. If we change Icon's nature, we're no longer having Icon. It'd be
better to support Idol instead, in that concern.
4/ My point about platform availability was about backward compatibility. I
know that nowaday's machines and system have C++ compilers available, but
Icon also runs on older machines/systems.
5/ and finaly, speed issue only speaks by benchmarking.

> My main concern with the icon-to-C  compiler was size and speed: it's not
> reasonable to use over a 3000 lines project which translate to >90000
lines
> of C, which then proceeds to exceed 80MB of memory to compile...

Actually, we should not forget one thing about Icon. Even though Icon looks
to my eye pretty young, fresh and complete, the fact is the first
implementation was made in 1979! I'm not sure when the C implemention has
started, but it's sure old. Most concepts of Icon implementation just rocks,
but it doesn't mean these are using the newer and better techniques.

> At a guess, the corresponding translation to C++ would be 10 times
smaller,
> and much more easy to tweak. But then, this means having someone with free
> time on their hands, and knowing C++...

Well, I agree on this. But good C code can be just similar. A *small*
reminder: C is a simple language, even though pointer arithmetics may drive
some crazy, it has few keywords and structures. C++ is a complex language,
it has full C compatibility, plus it has its own good and bad things. There
is a *lot* of concepts in C++ and avanced one are even not usually convered
by popular books.

There is many things that was not even concerned in the seventies and
eighties, such as resuability, portability, information hidding and stuff.
So, the techniques have lot changed and there is more and more valuable
documents on the newer way of implementing old concepts (nowaday's GC
implementations are just crazy, it almost worth any custom made memory
management. There is just almost no reason to not use GC now ::).

You should also dig into Squeak's Virtual Machine source code. You'd
probably be impressed how clean/clear their C implementation is made. Don't
forget it's generated C code, for most parts. I guess they found no reason
to implement it in C++. Squeak is much more portable than Icon, it runs on
everything gcc do (and runs virtually the same on every platform!), the only
exception is the need of bitblt functionalities.

Anyway, I still recall my primary concern was/is about dynamic primitive
data types in Icon. Wouldn't it be nice if..

Cheer, ::)
--
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/